fix(airplay): restore the transient pairing and control channel work lost in #42 - #43
Merged
Merged
Conversation
#42 was merged twelve seconds after #41, into `fix/airplay-hkp-header` — which #41 had just merged into master and left behind. The merge succeeded, so nothing looked wrong, but the commits landed on a branch nothing points at and master never received them. Master therefore has the `X-Apple-HKP` header from #41 and none of what it was a prerequisite for: the SRP proof still hashes g padded, transient pairing still runs M5/M6 and gets the connection closed, and there is no encrypted control channel. Pairing is broken on master in exactly the way #42 fixed. This restores #42's own diff — the eight `openplay-airplay` files it actually touched — on top of current master. Deliberately *not* a merge of `fix/airplay-hkp-header`. That branch was cut before #35, #36, #37, #39 and #40 merged, so a diff against it reads as deleting `openplay-discovery/src/address.rs` and reverting 244 lines of `openplay-sender/src/app.rs`. Merging it would silently undo five landed fixes. Only the range between #42 and its own parent is safe to replay, and that range touches nothing outside `openplay-airplay`. Verified after the replay: 233 tests pass, clippy and fmt clean, and the work from #35/#36/#37/#40 is still in the tree.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
#42 was stacked on #41. Twelve seconds after #41 merged that branch into master, #42 merged into the same branch — which master had already taken and moved past. Both merges reported success and both PRs show as merged, but #42's commits landed on a branch nothing points at.
Why it matters
Master currently has the
X-Apple-HKPheader from #41 and none of what it was a prerequisite for:gpadded → pair-setup fails at M4 with HAP error 2So AirPlay pairing on master is broken in exactly the way #42 fixed, while looking like it was fixed. This restores it.
Why this is a replay, not a merge
The obvious repair — merge
fix/airplay-hkp-headerinto master — is wrong and destructive. That branch was cut before #35, #36, #37, #39 and #40 merged, so its diff against master reads as:Merging it would silently undo five landed fixes to repair one. Only the range between #42 and its own parent is safe to replay, and that range touches nothing outside
openplay-airplay:That is what this PR contains — #42's content, unchanged, on top of current master.
Verification
cargo test --all— 233 passed / 0 failedclippy --all-targets --all-features -D warningsclean,fmt --checkcleanopenplay-discovery/src/address.rs(fix(discovery): sort discovered addresses by connectability #37), the row contrast fix (fix(sender): make receiver names readable on the unselected row card #35), the Miracast port field (feat(sender): let a manually added Miracast receiver specify its port #40), and theh264parsereordering (fix(pipeline): link the byte-stream capsfilter after h264parse, not before #36)Note for future stacked PRs
Merging a stack bottom-up in quick succession does this silently. Either merge the top of the stack first, or re-target the child PR to
masterand let GitHub recompute its diff before merging.